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DETAILED ACTION 

Response to Amendment 

It has been noted that claims 1,10, 14, 20, 24, 32, and 36 have been amended 
leaving claims 1-40 to be examined for consideration. 



Response to Arguments 

Applicant's arguments filed 6/5/2008 have been fully considered but are not 
persuasive. 

Regarding claim 1 , Applicant argues that the references combined do not teach 
claim 1 as amended which states "receiving a request from a first player to enable gate 
crashing in the game, wherein the game is configured in a single player mode." This 
argument is somewhat flawed because starting a game in "single player mode" implies 
that no other users can join the single player during game play. From an alternative 
point of view, it would be obvious to create a "multiplayer mode" game with just one 
player thereby allowing other players to "crash" or join the game, whether invited or not 
as taught from the combined references of Silvester, Finlayson, and the game Quake. 
Simply putting a label of "single player mode" in the claim language does not overcome 
the obviousness of these three combined references. 

Applicant also argues that that the combined references do not teach or disclose 
what is claimed in claim 14 for the argument that the host player or other players may 
be "aware" when a player joins the game. This is simply a game design choice that 
games such as Quake have implemented. It would be highly obvious to anyone skilled 
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in the art of gaming at the time of the invention to simply remove any kind of notification 
or status message which tells other players in a game when a new player has joined. By 
simply making other players unaware that a new player has joined the game and 
replaced one of the existing bots in the game is not novel at all. The combined 
references successfully teach that a player can join an existing game and transition 
control of a character in the game to the second player. 

Since all arguments have been address by the Examiner and are now moot, this 
rejection is FINAL. 

Claim Rejections - 35 USC § 103 

The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1 , 148 
USPQ 459 (1966), that are applied for establishing a background for determining 
obviousness under 35 U.S.C. 103(a) are summarized as follows: 

1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating 
obviousness or nonobviousness. 

Claims 1 -40 are rejected under 35 U.S.C. 1 03(a) as being unpatentable over 

Silvester (US 2003/01251 12 A1) in view of Finlayson et al (US 2002/0103029 A1) and 

the game manual for Quake III Arena 

("http://jarcas.dreamhosters.com/rdocs/Quake_lll_-_Manual_-_PC.pdf). 

Regarding claim 1, Silvester discloses a computer-implemented method for 
playing a game, the method comprising: 
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receiving a request from a first player to enable gate crashing in the game, 
wherein the game is configured in single-player mode (Silvester, Abstract and 
Paragraph 0008. Silvester states that "If the invitation is communicated to the 
invitee, the invitee may accept or reject the invitation." From an alternative point 
of view, it would be obvious to create a "multiplayer mode" game with just one 
player thereby allowing other players to "crash" or join the game.) ; 

in response to the request from the first player, transmitting information to a 
remote computer (Silvester, Paragraph 0016 and Figure 2. It would be obvious 
information would be transmitted among a plurality of remote computers to each 
other either directly or through a game server as it is commonly known in the 
art.); 

in response to transmitting the information to the remote computer, receiving a 
request from a second player to participate in the game (Silvester, Abstract); 
Silvester does not teach the following but Finlayson does: 

and 

in response to the request from the second player to participate in the game, 
transitioning control of a character in the game from a program routine to the second 
player (Finlayson, Summary of Invention. Finlayson teaches that when a user 
leaves a game, an Al bot replaces him until the user comes back. Therefore, it 
would be obvious in this case for a user to simply join a game and transition 
control of a character in the game from a program routine to the second player.). 
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The motivation for combining the teachings of Finlayson with Silvester is because 
both disclosures are related to multiplayer game networks. Even though Finlayson 
focuses the embodiment of his invention to multiplayer card games, it would be obvious 
to anyone skilled in the art of gaming to apply Finlayson's methods to other types of 
games such as RPGs, RTS, First Person Shooters, and so on. 

Therefore, it would be obvious to anyone skilled in the art of gaming at the time 
of the invention to combine the teachings of Finlayson with Silvester to achieve a 
multiplayer game method where a user can crash into a game and replace another 
character because it would create for better and enhanced game play. 

It should also be noted that Silvester does not teach that multiplayer gaming 
includes can include real players playing with virtual players like Finlayson does. It 
would be obvious however to combine Finlayson and Silvester with the game of Quake 
III, a multiplayer first person shooter game because a game or match would not have to 
end if multiple players leave a game. Instead, players that leave would be replaced with 
Al bots. In the same respect, a multiplayer game that already has Al bots can be 
replaced by crashers thereby allowing more real people to play in a game at once as 
well as keeping the game continuous and refreshing. 

Regarding claims 2, 16, Silvester, Finlayson, and Quake III disclose transmitting 
information to the remote computer includes transmitting information about the game to 
the remote computer (Obvious since games like Quake III are usually hosted on a 
server where multiple players can connect with each other to play a game. Game 
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information is obviously transmitted to all computers connected together in the 
game.). 

Regarding claims 3, 15, Silvester, Finlayson, and Quake III disclose transmitting 
information to the remote computer includes transmitting information about the first 
player to the remote computer (Obvious since games like Quake III are usually 
hosted on a server where multiple players can connect with each other to play a 
game. Game information is obviously transmitted to all computers connected 
together in the game.). 

Regarding claim 4, 17, Silvester, Finlayson, and Quake III disclose receiving a 
request from a second player to participate in the game includes receiving a non-player 
character selection from the second player (Silvester, Abstract discuses how a 
player can receive a request from another player to join a game. Combining this 
teaching with Finlayson who teaches about replacing non-player characters with 
a real player in a multiplayer game, it would be obvious then to have a second 
player to receive a request to join a game which includes receiving a non-player 
character selection from the second player.). 

Regarding claim 5, Silvester, Finlayson, and Quake III disclose transitioning 
control of a character in the game from a program routine to the second player includes 
transitioning control without signaling the first player (Silvester teaches that if a 
crasher wants to crash a game, the host of the game or the first player would be 
signaled as whether to accept or deny the person. It would then be obvious to 
have the opposite of this where the host is not aware that the crasher is joining a 
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game or not. It should also be noted that in multiplayer games like Quake III, even 
though it is not disclosed in the game manual, players have options to turn off 
status messages such as when players enter and leave a game. It should also be 
noted that in games like Quake III can support public and private game matches 
where in a public game match, anyone can crash into the game. With this in mind, 
a player can transition control of a character in the game from a program routine 
to the second player which includes transitioning control without signaling the 
first player.). 

Regarding claim 6, Silvester, Finlayson, and Quake III disclose a computer- 
implemented method for playing a game, the method comprising: 

receiving a request from a first player to initiate the game in single-player mode 
(In Quake III you can play the game in single player mode or multiplayer mode. 
However, in order to play a game with other real people, you would have to 
change the settings to multiplayer mode. It is also possible to play single player 
mode which would be simulated online in a network such as playing on server 
only with bots. It should be noted that there are classic games which includes 
Diablo 2 where players play the game online either by themselves or with other 
people.); 

receiving a first control input from the first player (Obvious in view of Silvester, 
Finlayson, and Quake); 

controlling a first character in response to the first control input received from the 
first player (Obvious in view of Silvester, Finlayson, and Quake); 
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controlling a second character in response to computer-readable instructions (As 
stated before, the Quake III manual teaches using bots (Quake III Manual, Page 
22), so therefore, you are in essence controlling a second or multiple characters 
in the game.); 

receiving a request from a second player to control the second character 
(Combining the teachings of Silvester and Finlayson, it is obvious for a second 
player to request to join a game and take control of the second character.).; 

in response to the request from the second player, transitioning control of the 
second character from the computer-readable instructions to the second player 
(Combining the teachings of Silvester and Finlayson, it is obvious for a second 
player to request to join a game and take control of the second character.); 

receiving a second control input from the second player (Obvious in view of 
Silvester, Finlayson, and Quake); 

and controlling the second character in response to the second control input 
received from the second player (Obvious in view of Silvester, Finlayson, and 
Quake). 

Regarding claim 7, Silvester, Finlayson, and Quake III disclose receiving a first 
control input from the first player includes receiving a first control input via a first game 
console operably connected to a first gaming system, and wherein receiving a second 
control input from the second player includes receiving a second control input via a 
second game console operably connected to a second gaming system remote from the 
first gaming system (Silvester, Figure 2). 
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Regarding claim 8, Silvester, Finlayson, and Quake III disclose transitioning 
control of the second character from the computer readable instructions to the second 
player includes transitioning control in the absence of notifying the first player 
(Finlayson, Summary of Invention. Finlayson teaches that when a user leaves a 
game, an Al bot replaces him until the user comes back. Therefore, it would be 
obvious in this case for a user to simply join a game and transition control of a 
character in the game from a program routine to the second player without 
notifying the first player.). 

Regarding claims 9, 19, Silvester, Finlayson, and Quake III disclose receiving a 
third control input from the second player; 

if the second character is still active in the game, controlling the second game 
character in response to the third control input received from the second player; and 

if the second character is no longer active in the game, controlling a third game 
character in response to the third control input received from the second player 
(Obvious. This is similar to a second player joining a game and replacing a 
character. Refer to arguments in claim 8 respectively). 

Regarding claims 10, 20, Silvester, Finlayson, and Quake III disclose a computer 
implemented method for playing a game, the method comprising: 

receiving information about one or more games from a remote computer, wherein 
the games are configured in single player mode (Obvious in view of Silvester, 
Finlayson, and Quake. From an alternative point of view, it would be obvious to 
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create a "multiplayer mode" game with just one player thereby allowing other 
players to "crash" or join the game); 

displaying at least a portion of the received information about the games (Quake 
III displays all the multiplayer games being hosted in a list in Multiplayer Mode as 
seen starting on page 20 of the game manual.); 

receiving a request to gate crash at least one of the games (Silvester teaches 
that if a crasher wants to join a game, the host of the game would receive a 
request and either choose to allow or deny the crasher); and 

in response to receiving to gate crash, transmitting the request to the remote 
computer (Obvious since the central computer or server would be in control as far 
as who is joining or leaving games during a multiplayer game session.). 

Regarding claim 11, Silvester, Finlayson, and Quake III disclose receiving 
information about one or more games from a remote computer includes receiving 
information about one or more non-player characters participating in the games, and 
wherein the method further comprises receiving a character selection corresponding to 
at least one of the one or more non-player characters (In Quake III in Multiplayer 
Mode, a user can select for example how many bots or non-player characters can 
be allowed to play in the game with real players.). 

Regarding claim 12, Silvester, Finlayson, and Quake III disclose sorting the 
information about the games, and wherein displaying at least a portion of the received 
information includes displaying at least a portion of the sorted information (The game 
Quake III arena has a "game lobby" where a list of current active games are 
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currently being played and where lobby information can be sorted based on name 
of game, ping/lag time, and so on. This is common in most multiplayer games.). 

Regarding claim 13, Silvester, Finlayson, and Quake III disclose transmitting the 
request to gate crash to the remote computer, implementing a peer-to-peer connection 
with a remote gaming system (It is obvious that in a game like Quake III arena, a 
peer-to-peer connection must be established for users on remote computers to 
connect to a server to play a multiplayer game.). 

Regarding claim 14, Silvester, Finlayson, and Quake III disclose a computer- 
readable medium having computer-executable instructions for performing steps 
comprising: 

receiving a request from a first player to enable gate crashing in a game 
(Silvester, Abstract and Paragraph 0008. Silvester states that "If the invitation is 
communicated to the invitee, the invitee may accept or reject the invitation."); 

in response to the request from the first player, transmitting information to a 
remote computer (Silvester, Paragraph 0016 and Figure 2. It would be obvious 
information would be transmitted among a plurality of remote computers to each 
other either directly or through a game server as it is commonly known in the 
art.); 

in response to transmitting the information to the remote computer, receiving a 
request from a second player to participate in the game (Silvester, Abstract); and 

in response to the request from the second player to participate in the game, 
transitioning control of a character in the game from a program route to the second 
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player, wherein the first player is not aware of the second player's participation in the 
game, and wherein the first player is not alerted to which character the second player 
controls (Finlayson, Summary of Invention. Finlayson teaches that when a user 
leaves a game, an Al bot replaces him until the user comes back. Therefore, it 
would be obvious in this case for a user to simply join a game and transition 
control of a character in the game from a program routine to the second player. It 
would be highly obvious to anyone skilled in the art of gaming at the time of the 
invention to simply remove any kind of notification or status message which tells 
other players in a game when a new player has joined. By simply making other 
players unaware that a new player has joined the game and replaced one of the 
existing bots in the game is not novel at all.). 

Regarding claim 18, Silvester, Finlayson, and Quake III disclose the first player 
controls a first character, and wherein transitioning control of a character in the game 
from a program routine to the second player includes transitioning control of a second 
character, and wherein the steps further comprise: 

receiving a first control input from the first player via a first game console 
operably connected to a first gaming system (Silvester, Figure 2 shows several 
computer systems or game consoles hooked up to a network for a multiplayer 
game such as Quake III); 

controlling the first character in response to the first control input received from 
the first player (Obvious in view of Silvester, Finlayson, and Quake); 
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receiving a second control input from the second player via a second game 
console operably connected to a second gaming system remote from the first gaming 
system (It would be obvious that a second player using a second control input via 
a second game console which is remote from the first game system as seen in 
Silvester, Figure 2.); and 

controlling the second character in response to the second control input received 
from the second player (Finlayson, Abstract and Summary of Invention teaches a 
second player taking control of a second character to join a multiplayer game.) 

Regarding claim 21, Silvester, Finlayson, and Quake III disclose receiving 
information about a game includes receiving information about a console-based game 
(Obvious since games like Quake III were made for multiple systems such as PC, 
Mac, and so on. It should be noted that a regular PC can be treated as a game 
console since a game console and a pc both have the same components to allow 
a user to play games.). 

Regarding claim 22, Silvester, Finlayson, and Quake III disclose receiving 
information about a game includes receiving information about a console-based game 
(Obvious in view of Silvester, Finlayson, and Quake), and wherein receiving a 
request from the second gaming system to join the console-based game includes 
receiving a character selection from the second gaming system (Obvious in view of 
Quake III and Finlayson.). 

Regarding claim 23, Silvester, Finlayson, and Quake III disclose the steps further 
compromise: 
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transmitting information about the game to a third gaming system (Obvious in 
view of Silvester, Figure 2.); 

receiving a request from the third gaming system to join the game (Obvious. 
Games like Quake III support multiple users requesting to join a game.); and 

in response to receiving the request from the third gaming system, establishing a 
peer-to-peer connection between the first and third gaming systems (Obvious. Quake 
III can support peer-to-peer connections between multiple gaming systems.). 

Regarding claim 24, Silvester, Finlayson, and Quake III disclose a computer- 
based system for implementing a game, the system comprising: 

means for receiving a request from a first player to allow control of a game 
character to be transitioned from a program routine to a remote player (Combining the 
teachings of Finlayson and Silvester respectively, it would be obvious that when 
a user requests to join a game, the player hosting the game would accept that 
remote player and allow him to take over a non-player character in the current 
game.). 

means for transmitting game-related information to a remote computer in 
response to the request from the first player, wherein the game is configured in single- 
player mode (Obvious in view of Sylvester, Finlayson, and Quake III respectively. 
From an alternative point of view, it would be obvious to create a "multiplayer 
mode" game with just one player thereby allowing other players to "crash" or join 
the game.); and 
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means for receiving a request from a second player to participate in the game in 
response to transmitting the information to the remote computer (Obvious in view of 
Silvester, Finlayson, and Quake). 

Regarding claim 25, Silvester, Finlayson, and Quake III disclose the means for 
receiving a request from a first player include means for receiving a request from a first 
player to allow control of a game character to be transitioned from a program routine to 
a remote player during the game without the knowledge of the first player (Combining 
the teachings of Finlayson and Silvester respectively, it would be obvious that 
when a user requests to join a game, the player hosting the game would accept 
that remote player and allow him to take over a non-player character in the 
current garner- 
Regarding claim 26, Silvester, Finlayson, and Quake III disclose the first player 
controls a first game character, and wherein the system further comprises means for 
enabling the second player to control a second character in response to the request 
from the second player to participate in the game (Obvious in view of Sylvester, 
Finlayson, and Quake III respectively). 

Regarding claim 27, Silvester, Finlayson, and Quake III disclose the first player 
controls a first game character (Obvious in view of Silvester, Finlayson, and Quake), 
and wherein the system further comprises means for transitioning control of a second 
character from a program routine to the second player (Finlayson teaches how a 
second character from a game can be transitioned to a second player joining the 
game). 
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Regarding claim 28, Silvester, Finlayson, and Quake III disclose the means for 
receiving a request from a second player to participate in the game include means for 
receiving a character selection from the second player (Obvious in view of Silvester, 
Finlayson, and Quake). 

Regarding claim 29, Silvester, Finlayson, and Quake III disclose the following: 

means for receiving a first control from the first player (Obvious in view of 
Silvester, Finlayson, and Quake); 

means for controlling a first character in response to the first control input 
received from the first player (Obvious in view of Silvester, Finlayson, and Quake); 

means for controlling a second character in response to computer-readable 
instructions (Obvious in view of Silvester, Finlayson, and Quake); 

means for controlling the second character in response to the second control 
input received from the second player( Finlayson teaches how a second character 
from a game can be transitioned to a second player joining the game. This part of 
the claim can also be interpreted as just a second player joining a game and 
controlling a second character which is also obvious in view of Quake III and all 
other previous multiplayer games.). 

Regarding claim 30, Silvester, Finlayson, and Quake III disclose means for 
establishing a peer-to-peer connection between a first gaming system on which the first 
player is playing and a second gaming system on which the second player is playing 
(Highly obvious in view of the game Quake III). 
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Regarding claim 31, Silvester, Finlayson, and Quake III disclose the means for 
transmitting game-related information include means for transmitting information about 
a console-based game from a first gaming system to a second gaming system (Highly 
obvious in view of the game Quake III). 

Regarding claim 32, Silvester, Finlayson, and Quake III disclose a computer- 
readable medium including a screen display (Obvious that the game system such as 
PC for playing a game like Quake III would have a display), the screen display 
comprising: 

at least one gate crasher selection field configured to receive an input from a first 
user, wherein the first user input enables control of at least one character in a related 
game to be transitioned from a program routine to a second player, wherein the related 
game is originally configured in single-player mode (Combining the teachings of 
Finlayson and Silvester respectively, it would be obvious that when a user 
requests to join a game, the player hosting the game would accept that remote 
player and allow him to take over a non-player character in the current game. In 
quake III for example, the host has options for certain settings such as the total 
number of people allowed to play in a game at once, how many bots can be 
playing at once, and so on. From an alternative point of view, it would be obvious 
to create a "multiplayer mode" game with just one player thereby allowing other 
players to "crash" or join the game.). 

Regarding claim 33, Silvester, Finlayson, and Quake III disclose the screen 
display further comprises: 
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at least one gate crasher attribute field configured to receive a user input 
establishing at least one attribute of potential gate crashes in the related game 
(Obvious in view of Silvester who teaches about gate crashing since it would be 
obvious to have a field configured to receive a user input.). 

Regarding claim 34, Silvester, Finlayson, and Quake III disclose the screen 
display further comprises: 

a gate crasher skill level field configured to receive a user input establishing a 
skill level of potential gate crashers in the related game (Silvester, Paragraph 0018 
teaches that a host can select the level of difficulty in the game. It would be 
obvious then that a users are at a certain skill level while playing a game.). 

Regarding claim 35, Silvester, Finlayson, and Quake III disclose the screen 
display further comprises: 

a gate crasher alias field configured to receive a user input identifying an alias of 
at least one potential gate crasher in the related game (Obvious since users in the 
game Quake III among other multiplayer games can set up user/alias names for 
themselves while playing games online with other people). 

Regarding claim 36, Silvester, Finlayson, and Quake III disclose a screen 
display, the screen display comprising: 

at least one gate crasher selection field configured to receive a user input, herein 
the user input enables the user to assume control of a character being controlled by a 
program routine in a related game being played on a remote gaming system, wherein 
the related game was originally configured in single-player mode (Combining the 
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teachings of Finlayson and Silvester respectively, it would be obvious that when 
a user requests to join a game, the player hosting the game would accept that 
remote player and allow him to take over a non-player character in the current 
game. In quake III for example, the host has options for certain settings such as 
the total number of people allowed to play in a game at once, how many bots can 
be playing at once, and so on. From an alternative point of view, it would be 
obvious to create a "multiplayer mode" game with just one player thereby 
allowing other players to "crash" or join the game). 

Regarding claim 37, Silvester, Finlayson, and Quake III disclose one or more 
fields configured to receive game filtering criteria (Obvious in view of Silvester, 
Finlayson, and Quake). 

Regarding claim 38, Silvester, Finlayson, and Quake III disclose a game type 
field configured to receive a user input indicating a type of game the user desires to 
crash (Obvious. Quake III displays all active multiplayer games a user may wish to 
crash.). 

Regarding claim 39, Silvester, Finlayson, and Quake III disclose a skill level field 
configured to receive a user input indicating a skill level of host players with which the 
user wishes to compete (Silvester, Paragraph 0018 teaches that a host can select 
the level of difficulty in the game. It would be obvious then that a users are at a 
certain skill level while playing a game.). 
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Regarding claim 40, Silvester, Finlayson, and Quake III disclose an alias field 
configured to receive a user input indicating an alias of a host player with which the user 
wishes to compete (Obvious in view of Silvester, Finlayson, and Quake). 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Thomas K. Cheriyan whose telephone number is 571- 
270-3225. The examiner can normally be reached on Mon-Fri 7:30AM-5:00PM EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Scott Jones can be reached on (571 )272-4438. The fax phone number for 
the organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a 
USPTO Customer Service Representative or access to the automated information 
system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 



/Scott E. Jones/ 

Primary Examiner, Art Unit 3714 



